FIG. 1 illustrates an Internet Protocol Virtual Private Network (IP-VPN) architecture. The architecture includes a plurality of VPN Sites, each of which includes a set of devices such as routers which share IP connectivity. Customer Edge (CE) devices (100) place VPN sites (104) in communication with Provider Edge (PE) devices (200), thereby allowing the VPN sites to communicate with other VPN sites (which belong to the same VPN) via the PE devices. The PE devices also allow remote access to other VPNs which are locally supported by the PE device. The PE devices track VPN routing information learned both locally and remotely. In MPLS networks, the PE devices also function as Label Edge Routers (LERs) which terminate Label Switched Path (LSP) tunnels used to forward traffic between PE devices. Provider (P) devices (102) are backbone routers which provides connectivity between PE devices. The Provider devices are not directly connected to any CE device and have no knowledge of VPN routes.
FIG. 2 is a block diagram of a typical prior art PE device (200) capable of IP-VPN operation. The prior art PE device has five major functional blocks: an IGP protocol (e.g., OSPF, IBGP etc.) across the core network connecting the remote PE devices; Virtual Route Forwarders (VRFS) for customer traffic separation; an MPLS subsystem for Label Switched Path (LSP) setup and maintenance; BGP with multi-protocol extensions (MP-iBGP) to exchange VPN routes and service labels with the remote PE devices; and an IP-VPN Forwarding plane to encapsulate the customer IP packet with two or more MPLS labels. The Virtual Route Forwarders (VRFS) provide traffic isolation between customers operating over the same node. A virtual router emulates the behavior of a dedicated hardware router by providing separate routing functionality, and is treated by the network as a separate logical router. Each VRF is capable of routing traffic among the IP interfaces directly connected to it without MPLS encapsulation. The IP-VPN block allows the interconnection of VRFs in several different PE devices and data traffic between the PEs. The MPLS subsystem is responsible for establishing, deleting, and maintaining label switched path (LSP) tunnels between PE routers using LDP or RSVP-TE. PE routers use BGP to distribute VPN routes to each other. Each VPN is allowed to have its own address space, which means that the same address can be used in any number of VPNs, wherein each VPN the address denotes a different system. If two sites of a VPN attach to PE routers, which are in the same Autonomous System, the PE routers can distribute VPN-IPv4 routes to each other by means of an IBGP connection between them. Alternatively, each can have an MP-BGP connection to a route reflector. Routes are learned from the core network and provided to LDP. LDP sets up LSPs with the PE devices connected to core network. Alternatively RSVP (with TE extensions) can be used to set up LSPs between PE devices. Local VRFs learn routes from CE devices and export them to BGP. BGP distributes these VPN routes along with the assigned service labels to other PE devices. BGP learns the VPN routes from other PE devices and distributes them to local VRFs. BGP will support multi-protocol extensions, route distinguisher, and route targets to achieve this. Using the service label that BGP learned for a VPN route and the LSP set up by the MPLS signaling protocol to the remote PE device, PE device software will create a tunnel in the data-path for the CE packets that need to reach the remote VRF. The PE device will perform a VPN route lookup upon receiving a packet from the CE device. If the result of the lookup is the remote VRF, then packets will be tunneled to the destination PE device. Typically, the PE router will encapsulate a packet from a CE device with two MPLS labels—a tunnel (outer) label is used for reaching the destined PE device, and a service (inner) label is used for VPN identification at the destination PE.
PE devices (200) are used successfully with MPLS core networks with IP-VPN architectures such as illustrated in FIG. 1 by large communications service providers. However, other large organizations in need of IP-VPN services in their own networks do not always favor MPLS core network solutions. For example, some large enterprises and universities have existing networks based on “pure IP,” and prefer to avoid migration to an MPLS core network because of the cost of acquiring new equipment and expertise. Further, some communications service providers may have need of an IP-VPN architecture with an IP core.
One technique for achieving an “IP core” IP-VPN is to implement GRE-IP tunnels between the PE routers, encapsulate the MPLS labeled packets with GRE-IP headers, and tunnel the packets across the routed core network. This technique has been proposed in the IETF draft: “Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks draft-ietf-13vpn-gre-ip-2547-05.” However, the technique requires MPLS equipment and expertise because MPLS is used to identify a VPN route, and an MPLS label stack is added to the VPN packets (between the ingress and egress PE router, the outermost member of the label stack will represent the VPN route label). Further, an MPLS-in-GRE or MPLS-in-IP encapsulation is used to convert the MPLS packet back into an IP packet (which creates a GRE or an IP tunnel between the ingress PE router and the egress PE router). This GRE-IP tunnel based solution has the complexity of a full mesh of GRE tunnels between PE devices. Further, because network complexity tends to increase and GRE tunnels are stateless, network convergence time may increase in the case of failure. Another technique, described in RFC4364, requires MPLS service and tunnel label encapsulation, including a label stack in the NLRI field. An alternative solution without the same drawbacks and requirements would be desirable.